Method and Arrangement For Handling A Subscription For Client Data

ABSTRACT

A method and arrangement for temporarily withholding notifications with client data of at least one observed client to a watching client when the watching client has an ongoing subscription for receiving the notifications from a client data server. When the watching client receives a subscription suspend trigger, the watching client sends a subscription suspend message to the client data server indicating that client data notifications should be temporarily withheld while retaining the subscription. When the watching client subsequently receives a subscription resume trigger, the watching client sends a subscription resume message to the client data server indicating that the suspended subscription shall be resumed and allowing client data notifications to be delivered again. The watching client then subsequently receives client data notifications according to the subscription.

TECHNICAL FIELD

The present invention relates generally to a method and arrangement forhandling a subscription for client data of an observed client. Inparticular, the present invention can be used to temporarily withholdclient data notifications to a watching client.

BACKGROUND

With the emergence of 3G mobile telephony, new packet-basedcommunication technologies using IP (Internet Protocol) have beendeveloped to support wireless communication of multimedia. For example,communication protocols in GPRS (General Packet Radio Service) and WCDMA(Wideband Code Division Multiple Access) support packet-switchedmultimedia services, as well as traditional circuit-switched voicecalls.

A network architecture called “IP Multimedia Subsystem” (IMS) has beendeveloped by the 3^(rd) Generation Partnership Project (3GPP) as aplatform for handling multimedia services and sessions in the packetdomain, based on IP transport. Thus, an IMS network can be used toinitiate and control multimedia sessions for any IP enabled terminalsbeing connected to any type of access networks. A signalling protocolcalled “SIP” (Session Initiation Protocol, according to the standardIETF RFC 3261) is typically used for handling sessions in IMS networks.A “SIP-enabled” terminal can thus use this standard to initiate andterminate multimedia communications with other terminals and servers bymeans of its home IMS network.

FIG. 1 is a simplified schematic illustration of a basic networkstructure for providing multimedia services for a client using aterminal A by means of an IMS network 100. In this example, terminal Ais a mobile terminal connected to a radio access network 102, eventhough IMS can be used for fixed terminals as well. An IMS terminal isoften generally referred to as “User Equipment (UE)”.

The access network 102 is connected to IMS network 100, which is the“home” IMS network of terminal A and therefore handles multimediaservices for terminal A. Basically, multimedia services are handled bythe terminal's home IMS network even when roaming in a visited accessnetwork. Any multimedia sessions and services for the client of terminalA are controlled by specific session managing nodes in the IMS network100, including a P-CSCF (Proxy Call

Session Control Function) node 104, an S-CSCF (Serving Call SessionControl Function) node 106, and an I-CSCF (Interrogating Call SessionControl Function) node 108, according to the conventional IMSarchitecture of today.

Briefly described, the P-CSCF node 104 acts as the entry point forclients towards the IMS network 100 from access networks, includingnetwork 102. A plurality of S-CSCF nodes in the IMS network 100 areassigned to different active terminals for managing their sessions usingSIP signalling, and the shown S-CSCF node 106 handles sessions forterminal A in this example. Further, the I-CSCF node 108 acts as agateway basically receiving SIP messages from other IMS networks 110.

The IMS network 100 also includes one or more application servers 112for different multimedia services, and a main database node HSS (HomeSubscriber Server) 114 where various subscriber and authentication datais stored for clients. The various functions of the shown networkelements in IMS network 100 are generally known in the art, but are notnecessary to describe here further to understand the context of thepresent invention.

Each application server 112 supports one or more specific multimediaservices such as “Instant Messaging” (IM), “Push-to-talk over Cellular”(PoC) and “Presence”, where SIP signalling is used to control sessions.In particular, presence services basically make data related to anobserved client available to other watching clients.

In this description, the term “presence data”, or generally “clientdata”, is used to represent information on the state or situation of aclient and his/her equipment in any predefined respect. Brieflydescribed, presence data of a client is published by storage at anapplication server generally referred to as a “presence server”, whichcan be supplied to other clients subscribing to that presence data. Thepresence data may refer to the following exemplary client states:

-   A personal status, e.g. available, busy, in a meeting, on holiday,    etc.-   A terminal status, e.g. switched on/off, engaged, out of coverage,    etc.-   The geographic location of the client/terminal.-   Terminal capabilities, e.g. functionality for SMS, MMS, chat, IM,    video, etc.-   Terminal selections, e.g. call forwarding, language, etc.-   Other client information, e.g. interests, occupations, personal    characteristics, moods, personal logos, logo depending on the    current mood, etc.

This type of information is continually stored in presence servers inthe IMS network, based on publications of so-called “client events”received from clients or from their access networks, whenever anypresence data for a client is introduced, updated, changed or deleted. Aclient may thus also subscribe for selected presence data of one or moreother clients which is also handled by an application server in the IMSnetwork.

In this description, the term “client” will be used to generallyrepresent a user equipment (or communication terminal) and its user.Further, the term “watching client” represents a client that subscribesor requests for presence data (sometimes also referred to as the“Watcher”), and the term “observed client” represents a client thatpublishes presence data (sometimes also referred to as the “Presentity”)to be available for authorised watching clients.

A SIP message called “SIP PUBLISH” is generally used by observed clientsto send their presence data to the presence server for publication. TheSIP PUBLISH message can be used basically in four different cases,namely: 1) to initiate new data, 2) to “refresh” data (i.e. confirmingthat earlier initiated data continues to be valid), 3) to modify data,and 4) to terminate data no longer valid.

Another SIP message called “SIP SUBSCRIBE” is used by watching clientsto subscribe for presence data of observed clients, and only authorisedclients are entitled to receive such data. The SIP SUBSCRIBE message canbe used to obtain presence data either just once or on plural occasions,as determined by a time-out parameter that can be set in that message,often referred to as TTL, “Time To Live”.

If the time-out parameter in a SIP SUBSCRIBE message is set to zero, anotification with requested presence data is obtained just once and thesubscription is promptly terminated thereafter. If the time-outparameter is set to a certain time period>0, the watching client willreceive notifications until the subscription period expires.Notifications can then be received either automatically using a“push”-type mechanism, e.g. regularly or whenever the data is changed,or upon demand using a “pull”-type mechanism.

FIG. 2 illustrates the present conventional procedure for providingpresence data, involving the user equipment A of a watching client andthe user equipment B of an observed client belonging to an IMS networkcomprising a presence server 200 acting for client B. The presence datafor client B is maintained in a presence database 202 associated withpresence server 200. As shown in the figure, clients A and B arerepresented by mobile terminals even though the described procedure canbe applied for fixed terminals as well.

A first step 2:1 a generally illustrates that the observed client Bpublishes presence data by frequently sending SIP PUBLISH messages tothe presence server 200 according to conventional routines, as describedabove. Certain data for client B can also be sent from client B's accessnetwork (not shown), e.g. location data and terminal status data. A nextstep 2:1 b illustrates that database 202 is updated accordingly inresponse to receiving the SIP PUBLISH messages of step 2:1 a. Steps 2:1a and 2:1 b continue throughout in the background, according toprevailing routines.

Client A can subscribe to specific presence data by establishing adialogue with the presence server in which notifications can bereceived. In a step 2:2, client A thus sends an SIP SUBSCRIBE message asa subscription request for presence data of client B, in which a desiredsubscription time period is specified for the dialogue. As mentionedabove, if the client A wants to receive presence data of client B justonce (the pull mechanism), the subscription time=0, but if he/she wantsto receive presence data over a longer period (the push mechanism), thesubscription time>0. The presence server 200 then retrieves presencedata of client B in a step 2:3, and sends it to client A in an initialnotification message SIP NOTIFY, as shown in a step 2:4.

As indicated by the dashed arrows, client A may receive suchnotifications on further occasions during the given subscription time,either at regular intervals or whenever the presence data is changed.The presence server will also reserve certain server resourcesthroughout the subscription period needed to maintain the subscriptionand provide the desired presence data of client B to client A, includingcommunication and processing resources to receive and forwardnotifications. In order to prolong or “refresh” the subscription, clientA may send further SIP SUBSCRIBE messages just before the subscriptiontime expires, and the presence server will then continue to maintain thesubscription and the associated resources.

A watching client may also subscribe to presence data of plural observedclients, which often results in numerous notifications for updatedpresence data being sent to the watching client. An information deliveryserver has therefore been proposed called the RLS, “Resource ListServer” acting to collect notifications from the observed clients inorder to send a single notification for all observed clients to thewatching client. This mechanism is sometimes called the “exploder”function. Another solution for reducing the number of notifications byusing a combined push/pull mechanism, is disclosed in WO 2005/088949(Telefonaktiebolaget LM Ericsson AB).

However, if the client user do not want to receive any presencenotifications during a limited period, e.g. when not wanting to bedisturbed or when being occupied in a session or call or otherwise, thesubscription must be terminated. In order to resume the notifications,the subscription must then be re-created, i.e. a completely newsubscription must be established. This procedure will now be brieflydescribed with reference to a block diagram in FIG. 3 containing awatching client A, a presence server 300 providing presence data on anobserved client B (not shown), as well as a P-CSCF node 302 and anS-CSCF node 304 in an IMS network of the watching client A. It isassumed that a subscription has been created basically in the mannerdescribed for FIG. 2 above, and that client A frequently receivesnotifications with presence data of client B, accordingly.

The user of client A has now decided to withhold the notificationsduring a period of time, for some reason, and terminates thesubscription by means of a suitable input command in the used terminal.In a first step 3:1, client A therefore sends a subscription requestmessage in the current dialogue to the P-CSCF node 302 with the TTL orsubscription time set to zero, such as: SIP SUBSCRIBE (expires=0), inorder to terminate the ongoing subscription. The P-CSCF node 302 thenroutes the subscription request message to the presence server 300, in astep 3:2.

The presence server 300 then terminates the subscription and releasesall server resources being reserved for the subscription, as indicatedby a further step 3:3. Server 300 may also send a final notification toclient A at this point, not shown. This means of course that no furtherpresence notifications on client B will be communicated to client A.

When the user of client A later wants to re-create his/her presencesubscription, a new dialogue must be established with server 200 and anew subscription request message is sent to the P-CSCF node 302, in anext step 3:4, such as: SIP SUBSCRIBE (expires>0). The P-CSCF node 302then routes the subscription request message to the S-CSCF node 304which is given in the request, in a following step 3:5, to re-create thesubscription. It should be noted that the S-CSCF node 304 is needed forrouting the request to the correct destination, being a request for acompletely new subscription. The S-CSCF node 304 accordingly routes thesubscription request message of client A to the presence server 300, ina further step 3:6. The presence server 300 will thus establish a newsubscription for client A, which involves checking whether client A isauthorised to receive presence data of client B as well as reservingvarious needed server resources for the subscription.

FIG. 4 illustrates a similar procedure when the watching client Asubscribes for presence data of plural observed clients B, C, D . . . bymeans of an RLS node 400. The block diagram of FIG. 4 likewise containsa P-CSCF node 302 and an S-CSCF node 304 in an IMS network of thewatching client A. Further, plural presence servers 402 are shownproviding presence data on the observed clients B, C, D . . . ,respectively. It is assumed that client A frequently receivesnotifications with presence data of the observed clients from the RLSnode 400, by means of an established RLS subscription. RLS node 400 hasalso established individual back-end subscriptions with the presenceservers 402 for each of the observed clients.

Client A decides to withhold the notifications temporarily andterminates the RLS subscription by sending a terminating SIP SUBSCRIBErequest (expires=0) within the existing dialogue to the P-CSCF node 302,in a first step 4:1. The P-CSCF routes the request to the RLS node 400in a step 4:2. The RLS must now terminate all existing back-endsubscriptions with presence servers 402, which may be in the range of10-100, and thus sends terminating SIP SUBSCRIBE requests (expires=0)within the existing dialogues for each presence server subscription, asillustrated in a step 4:3. The RLS node will then naturally receive nofurther notifications from the presence servers 402.

Sooner or later, client A decides to re-create the subscription andsends an initial SIP SUBSCRIBE request (expires>0) to the P-CSCF 302, ina next step 4:4. The P-CSCF accordingly routes the request to the S-CSCF304 handling the resource pointed out in the request, in a followingstep 4:5. The S-CSCF then routes the request to the RLS node 400 tocreate the RLS subscription for client A, in a next step 4:6.

The RLS node 400 now creates a back-end subscription for each presenceserver 402 being pointed out by the initial RLS subscription (which maybe predefined or ad-hoc), and sends an initial SIP SUBSCRIBE request tothe S-CSCF node 304 for the presence server subscriptions, in a furtherstep 4:7. Finally, the S-CSCF node 304 routes a subscription request toeach presence server 402 to activate the respective subscriptions, in astep 4:8.

In the above-described conventional solutions of terminating thesubscription to withhold notifications, considerable efforts andsignalling are required to terminate and re-create presencesubscriptions in this manner, as several messages must be communicatedbetween different network nodes and elements, also introducing latency.Re-creating the subscription further requires that a new dialogue isestablished between the watching client and the presence server, havingreleased the previous dialogue to withhold the notifications.

Further, any client publications and presence updates occurring duringthe suspension period will never be notified to the watcher. Inparticular, when an RLS is used in the case of a subscription for pluralobserved clients, different presence servers of those clients willcontinuously send notifications to the RLS that will be lost in thecurrent solution. Hence, it would be desirable to avoid or at leastreduce the problems above when temporarily withholding notificationswith presence or client data to watching clients.

SUMMARY

The object of the present invention is to address the problems outlinedabove. In particular, it is an object of the present invention toprovide a solution that can generally reduce the signalling and numberof messages necessary for temporarily withholding notifications withclient or presence data regarding one or more observed clients.

These objects and others may be obtained by using a method andarrangement according to the attached independent claims.

According to one aspect, the present invention provides a method ofwithholding notifications with client data of at least one observedclient, as executed by a user equipment of a watching client. Thewatching client has an ongoing subscription for receiving thenotifications from a client data server. When a subscription suspendtrigger is received, a subscription suspend message is sent to theclient data server indicating that client data notifications should betemporarily withheld while still retaining the subscription. When asubscription resume trigger is received later, a subscription resumemessage is sent to the client data server indicating that client datanotifications should be delivered again. Client data notifications arethen received as normal according to said subscription.

Buffered client data notifications may be received retroactively inresponse to the subscription resume message, after being buffered by theclient data server during the suspension period.

The client data notifications may relate to plural observed clients, andthe client data server may be a client data aggregating server receivingclient data notifications from plural client data server associated withthe observed clients.

Any of the subscription suspend and resume messages may be an SIPSUBSCRIBE message with a specific indication that the subscription shallbe suspended or resumed, respectively, either included in a new headeror added as an optional parameter to an existing header in the SIPSUBSCRIBE message.

If an IMS network is used, the subscription suspend and resume messagesare first routed to a P-CSCF node in the IMS network for further routingto the client data server.

Only notifications of specific observed clients and/or specificnotification event types may be withheld, while other notifications areallowed to be received during the suspension period.

The subscription suspend trigger may be received as a manual user inputcommand, or automatically when the user is occupied in a session or callor when the user has been inactive for a preset duration. Thesubscription resume trigger may also be received as a manual user inputcommand, or automatically when a session or call is finished or when theuser becomes active again after a period of inactivity.

According to another aspect, the present invention provides anarrangement in a user equipment of a watching client, comprising meansfor executing the method above.

According to yet another aspect, the present invention provides a methodof withholding notifications with client data of at least one observedclient to a watching client, as executed by a client data server adaptedto provide the notifications. Again, the watching client has an ongoingsubscription for receiving the notifications from the client dataserver. When a subscription suspend message is received from thewatching client, the client data notifications are withheld while stillretaining the subscription and server resources needed for providing thenotifications. When a subscription resume message is later received fromthe watching client, client data notifications are again sent to thewatching client as normal according to the subscription.

Client data notifications are preferably buffered during the suspensionperiod, and the buffered client data notifications may be delivered tothe watching client retroactively in response to the subscription resumemessage.

Only notifications of specific observed clients and/or specificnotification event types may be delivered retroactively after thesuspension period, while other notifications are discarded.

The client data notifications may relate to plural observed clients, andthe client data server may be a client data aggregating server receivingclient data notifications from plural client data servers associatedwith the observed clients according to individual back-endsubscriptions. All or some of the back-end subscriptions with the clientdata servers may then be suspended during the suspension period.

Only some notifications of specific observed clients and/or specificnotification event types may be withheld, while other notifications areallowed to be delivered during the suspension period.

According to yet another aspect, the present invention provides anarrangement in a client data server, comprising means for executing themethod above.

Further features of the present invention and its benefits can beunderstood from the detailed description below.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will now be described in more detail by means ofexemplary embodiments and with reference to the accompanying drawings,in which:

FIG. 1 is a schematic overview of an IMS network capable of providingmultimedia services for a terminal A, according to the prior art.

FIG. 2 is a block diagram illustrating a conventional procedure forobtaining presence data of an observed client, according to the priorart.

FIG. 3 is a block diagram illustrating a conventional procedure forwithholding notifications with presence data of an observed client,according to the prior art.

FIG. 4 is a block diagram illustrating a conventional procedure forwithholding notifications with presence data of plural observed clientsusing an RLS node, according to the prior art.

FIG. 5 is a block diagram illustrating a procedure for withholdingnotifications with client data of an observed client, according to oneembodiment.

FIG. 6 is a flow chart with steps in a procedure executed by a userequipment of a watching client for withholding notifications with clientdata of an observed client, according to another embodiment.

FIG. 7 is a flow chart with steps in a procedure executed by a clientdata server for withholding notifications with client data of anobserved client, according to yet another embodiment.

FIG. 8 is a block diagram illustrating a procedure for withholdingnotifications with client data of plural observed clients using an RLSnode, according to yet another embodiment.

FIG. 9 is a block diagram illustrating a user equipment of a watchingclient and a client data server capable of providing client data of oneor more observed clients, according to further embodiments.

DETAILED DESCRIPTION

Briefly described, the present invention can be used for temporarilywithholding notifications with client or presence data to a watchingclient, without requiring the termination and re-creation of a clientdata subscription. The subscription and associated resources in a serverproviding client data are thus maintained throughout the period ofsuspension, although no notifications are to be sent during this periodto the watching client.

In order to initiate a suspension period, the watching client sends asubscription suspend message to the client data server containinginformation indicating that the subscription shall be temporarilysuspended. Later, the watching client sends a subscription resumemessage containing information indicating that the suspendedsubscription shall be resumed, allowing client data notifications to bedelivered again.

Any pending client data notifications may be either buffered at theclient data server to be delivered “retroactively” to client A once thesubscription is resumed, or simply discarded during the suspensionperiod. These options could be determined by the client user, e.g. byincluding different sub-information in the subscription suspend requestor by means of preset client preferences. The actual subscription willbe maintained as normal in the presence or client data server, apartfrom not sending notifications, and should be refreshed not to expireaccording to regular procedures during the suspension period.

Suspending the subscription can be triggered either by a manual inputcommand from the user, e.g. when not wanting to be disturbed, orautomatically by the terminal itself when the client is occupied in asession or call or has been inactive for a preset duration, e.g., by notusing the key pad or retrieving the address book, etc. In the samemanner, resuming the subscription can also be triggered either by theuser or the terminal.

In the following description, the term “presence data” will be used torepresent any client data that is made available, or “observed”, asdescribed above. Even though the following embodiments are generallydescribed in terms of presence services, the invention is not limitedthereto but can be implemented for any applications and services usingthe client data subscribe mechanism.

Further, the “client data server” in the below embodiments could be anyserver capable of providing requested client data of one or moreobserved clients to authorised watching clients, e.g. a presence serveror RLS node as described for FIGS. 3 and 4, respectively. Reference willalso be made to well-known SIP messages, although the present inventionis generally not limited thereto.

An embodiment will now be described with reference to a signallingprocedure in a block diagram shown in FIG. 5, involving a watchingclient A, a session control node 500 such as a P-CSCF node, and a clientdata server 502 capable of providing client data of an observed client B(not shown). It is assumed that a subscription has been created forclient data notifications as described above, and that client Aaccordingly receives notifications with presence data of client B fromclient data server 502 in an ongoing dialogue. If an IMS network isused, it is not necessary to involve the S-CSCF node for creating a newsubscription in this embodiment, in contrast to the prior art procedureof FIG. 3.

Initially, the user of client A decides to suspend the subscriptiontemporarily, as triggered by a suitable manual input command in the usedterminal. Alternatively, the terminal itself may also trigger suspensionof the subscription automatically as described above, e.g. when occupiedin a session or call. The suspension trigger is illustrated as a firststep 5:1. In either case, client A sends a subscription suspend requestto the session control node 500 within the existing dialogue, in a nextstep 5:2. In an IMS network, the subscription suspend request can be anSIP SUBSCRIBE message with a specific indication that the subscriptionshall be suspended. This indication can either be included in a newheader or added as an optional parameter to an existing header in theSIP SUBSCRIBE message.

In this case, it is not necessary to provide an expiry time for thesubscription specifically in the suspend message, being independent ofthe routine of refreshing the subscription which is still maintainedduring the suspension period, as described above. However, it ispossible to follow the prevailing standard for SIP SUBSCRIBE messagesand provide a new expiry time>0 in the suspend message at this point,depending on the implementation.

The session control node 500 then routes the subscription suspendrequest to the client data server 502, in a step 5:3. Thereby, server502 suspends the subscription by not sending any notifications to clientA for the time being, but retains all server resources reserved for thesubscription for registering received publication messages from clientB. It should be noted that the existing dialogue between client A andclient data server 502 is still retained throughout the suspensionperiod.

At the same time, server 500 preferably buffers any client datanotifications that would otherwise be sent to client A according to thesubscription, which is illustrated by a step 5:4. Alternatively, anycurrent client data notifications may be simply discarded during thesuspension period. The handling of pending client data notificationsduring the suspension period may be determined by the client user, e.g.as indicated in the subscription suspend request or according topredetermined preferences stored in the network as client parameters.

At some point later, client A will resume the subscription again, whichmay be triggered by another manual input command from the user, orautomatically by the terminal itself, e.g., when a session or call isfinished or when the user gets active again after a period ofinactivity. The resume trigger is illustrated as a further step 5:5. Ineither case, client A sends a subscription resume request to the sessioncontrol node 500 within the still retained dialogue, in a next step 5:6.

In an IMS network, the subscription resume request can be an SIPSUBSCRIBE message with a specific indication that the subscription shallbe resumed, as similar to the suspend request of step 5:2. Thus, theresume indication may be either included in a new header or added as anoptional parameter to an existing header in the SIP SUBSCRIBE message.

In a next step 5:7, the session control node 500 then routes thesubscription resume request to the client data server 502 where thesubscription is resumed. In response thereto, server 502 will send allbuffered notifications to client A, if any, and also furthernotifications as they occur according to regular procedures, asillustrated in a final step 5:8.

The above-described procedure of FIG. 5 can be modified in differentways. For example, only some notifications, e.g. specific observedclients and/or specific notification event types, may be withheld duringthe suspension period whereas others are allowed to be delivered toclient A. Such a selective notification delivery which may be controlledaccording to a filter function or the like. This filter may be specifiedin the subscription suspend request of step 5:2, or may be predefined inthe network as a preference of client A. Further, it is possible todeliver only some of the buffered notifications after the suspensionperiod, whereas others could be discarded by means of a similar filterfunction as above for, e.g., specific observed clients and/or specificnotification event types.

In FIG. 6, a flow chart is shown of a procedure executed by a userequipment of a watching client for withholding notifications with clientdata of an observed client, according to another embodiment. Thisprocedure may basically correspond to the example shown in FIG. 5 withrespect to client A. Thus, it is assumed that the watching client has anongoing subscription for notifications with client data of one or moreobserved clients, and that a dialogue has been established with a clientdata server or RLS providing the notifications.

In a first step 600, a subscription suspend trigger is receivedindicating that no notifications should be communicated for the timebeing. The suspend trigger may be received either from the user orautomatically in response to the establishment of a session or call, orwhen the user has been inactive for a preset period of time.

In a next step 602, a subscription suspend message is sent to the clientdata server or RLS providing the notifications, which may be routed overa session control node such as a P-CSCF node in an IMS network, as shownin FIG. 5. The subscription suspend message includes an indication thatno notifications should be sent to the watching client, as describedabove for step 5:2 in FIG. 5.

In a further step 604, a subscription resume trigger is receivedindicating that the communication of notifications should be resumedagain. In a similar manner, the resume trigger may be received eitherfrom the user or automatically in response to the termination of asession or call, or when the user becomes active after a period ofinactivity. A subscription resume message is then sent to the clientdata server or RLS providing the notifications, in a next step 606,including an indication indicating that notifications should bedelivered to the watching client again, as described above for step 5:6in FIG. 5. The resume message may be likewise routed over a sessioncontrol node (e.g. P-CSCF node).

In a final and optional step 608, any buffered notifications may bereceived, if such notifications are pending and depending on whethernotification buffering is required in the client data server or RLS. Anyfollowing regular notifications will also be received as well, notshown.

In FIG. 7, a flow chart is shown of a procedure executed by a clientdata server or the like for withholding notifications with client dataof an observed client to a watching client, according to yet anotherembodiment. This procedure may basically correspond to the example shownin FIG. 5 with respect to client A, but may also be executed by an RLSnode or similar acting as an exploder for plural observed clients.Further, the watching client basically acts according to the flow chartof FIG. 6. Thus, it is assumed that the watching client has an ongoingsubscription for notifications with client data of one or more observedclients, and that a dialogue has been established with the watchingclient for providing the notifications.

In a first step 700, a subscription suspend message is received from thewatching client as of step 602 in FIG. 6. The subscription is thensuspended accordingly in a step 702 but not terminated, also retainingthe existing dialogue with the watching client. Naturally, no finalnotification is sent at this point in contrast to the conventionalsolution.

During the suspension period, the client data server may continue toreceive client data notifications for the observed client(s) which maybe buffered as pending notifications for later delivery to the watchingclient, as illustrated by a next optional step 704. As described above,the question whether notifications should be buffered or discardedduring the suspension period may be subject to the watching client'spreferences.

At some point later, a subscription resume message is received from thewatching client as of step 606 in FIG. 6, in a further step 706. Thesubscription is then resumed accordingly in a final step 708, and anybuffered notifications are optionally sent to the client, depending onwhether notification buffering is required in the client data server orRLS and if such notifications are pending. It may be preferred that aninitial notification is normally sent when resuming a subscription. Anyfollowing regular notifications will of course also be sent to theclient as well, not shown.

The present invention can also be used when a watching client subscribesto client data according to a list of plural observed clients, where anRLS node or the equivalent is used for providing aggregatednotifications, as mentioned above.

FIG. 8 is a block diagram illustrating a procedure for withholdingnotifications with client data of plural observed clients using a clientdata aggregating server 800 and a session control node 802 such as aP-CSCF node, according to yet another embodiment. The client dataaggregating server 800 is capable of providing aggregated client datanotifications on plural observed clients in the manner of an RLS node orexploder, based on individual back-end subscriptions for notificationsfrom their respective client servers 804, as described above. It isassumed that client A receives notifications from the aggregating server800 in an ongoing dialogue according to a previously createdsubscription. Again, it is not necessary to involve an S-CSCF node in anIMS network for creating new subscriptions with multiple client dataservers in this embodiment, in contrast to the conventional procedure ofFIG. 4.

Several steps in FIG. 8 correspond to steps in the procedure illustratedin FIG. 5, and it is therefore not necessary to repeat the detaileddescription here. A suspension trigger is illustrated as a first step8:1, as in step 5:1 in FIG. 5. In response thereto, client A sends asubscription suspend request to the session control node 804 within theexisting dialogue, in a next step 8:2, which may be an SIP SUBSCRIBEmessage, as in step 5:2 in FIG. 5. The session control node 802 thenroutes the subscription suspend request to the aggregating server 800,in a step 8:3.

Server 800 then suspends the subscription but retains all serverresources reserved for the subscription as well as the existing dialoguewith client A and all back-end subscriptions with the client dataservers 804. This means that server 800 will continue to receivenotifications from client data servers 804 according to the back-endsubscriptions, as illustrated by a schematic step 8:4. During thesuspension period, server 500 may buffer these notifications or they maybe discarded in a step 8:5, as in step 5:4 in FIG. 5. Alternatively, theclient data aggregating server 800 may suspend all or some of theback-end subscriptions with the client data servers 804 during thesuspension period, and no notifications will then be received from thoseclient data servers 804. In the case of extensive suspension periods,the watching client A or the client data aggregation server 800 maydecide to suspend the back-end subscriptions.

A resume trigger is illustrated in a step 8:6, and client A sends asubscription resume request to the session control node 802 within theexisting dialogue in a step 8:7, thus wholly corresponding to steps 5:6and 5:7 in FIG. 5, respectively. Again, the subscription resume requestas well as the earlier subscription suspend request may be SIP SUBSCRIBEmessages as described for FIG. 5.

The session control node 802 then routes the subscription resume requestto the aggregating server 800 in a further step 8:8, and server 800 willinitially send the buffered notifications to client A, if any, and alsofurther notifications according to regular procedures, in a final step8:9.

FIG. 9 is a block diagram illustrating in more detail a user equipment900 of a watching client A and a client data server 902 when providingclient data of one or more observed clients (not shown) to the watchingclient, according to further embodiments. The various components in thefigure are merely illustrated as logical functional units and can beimplemented by means of any suitable combinations of hardware andsoftware.

The user equipment 900 comprises a user input unit 900 a adapted toprovide subscription suspend and resume triggers in response to manualuser input commands. A trigger unit 900 b may also be arranged toprovide a subscription suspend triggers automatically. The user inputunit 900 a and the trigger unit 900 b are adapted to operate basicallyin the manner described for steps 5:1 and 5:5 in FIG. 5, and for steps8:1 and 8:6 in FIG. 8, respectively.

The user equipment 900 further comprises a logic unit 900 c adapted tocreate a subscription suspend message and a subscription resume messagein response to the above-described triggers. A communication unit 900 dis adapted to send the created subscription suspend and resume messagesS, R to the client data server 902, basically in the manner describedfor steps 5:2 and 5:6 in FIG. 5, and for steps 8:2 and 8:7 in FIG. 8,respectively. The communication unit 900 d is also adapted to receivenotifications N from the client data server 902, basically in the mannerdescribed for step 5:8 in FIG. 5, and for step 8:9 in FIG. 8,respectively.

The client data server 902 comprises a notification receiving unit 902 aadapted to receive client data notifications N regarding the one or moreobserved clients, from the clients themselves or from their networks, orfrom associated client data servers based on back-end subscriptions, asdescribed for step 8:4 in FIG. 8.

The client data server 902 further comprises a logic unit 902 b adaptedto suspend and resume the subscription and create client datanotifications to the watching client. The logic unit 902 b may also beadapted to store notifications N received during a suspension period ina buffer memory 902 c, if required to do so, basically in the mannerdescribed for step 5:4 in FIG. 5, and for step 8:5 in

FIG. 8, respectively.

A communication unit 902 d in client server 902 is adapted to receivesubscription suspend and resume messages S, R from client A's userequipment 900, and the logic unit 902 b is further adapted to controlthe subscription accordingly. The communication unit 902 d is alsoadapted to deliver client data notifications to the watching client,basically in the manner described for step 5:8 in FIG. 5, and for step8:9 in FIG. 8, respectively.

A watching client that wants to use the suspend/resume function needs away to discover if the client data server supports the function. Thiscan be done according to three alternatives described below:

-   1) The watching client may indicate in the initial subscription    request that it supports the suspend/resume function, such that the    client data server can indicate in a response whether it supports    the function or not.-   2) The client data server may indicate by default in all regular    responses in an ongoing dialogue that it supports the suspend/resume    function.-   3) The watching client may send a subscription suspend request, and    if the client data server does not support the suspend/resume    function will then return a regular response plus a full    notification message. The client can then stop using the function    for this dialogue.

The present solution can also be configurable and not only controlled bythe terminal in real time. This would mean that the user of the watchingclient or his/her operator can determine and configure specificoccasions or time periods when a client data subscription shall betemporarily suspended. Other entities in the watching client's accessnetwork, such as stateful proxies being aware of the existingsubscriptions, may also suspend subscriptions at specific occasions ortime periods occasions, such as when parts of the access network areunavailable or subject to heavy loads.

The present invention can be used to suspend/resume subscriptionswithout having to terminate and create the subscriptions, thereby savingconsiderable efforts and signalling activities. In general, thefollowing advantages can be mentioned:

-   1) The subscription can be suspended temporarily by using existing    mechanisms with small extensions to the existing standard requests    (e.g. a new additional header or extra data in an existing header).    It is only necessary to adapt the watching client's user equipment    and the client data server for implementing the suspend/resume    function. Thus, any existing proxies such as IMS Core are not    affected.-   2) The suspension can be done without loosing notifications being    generated during the suspension period. This is particularly useful    in the case of an exploder function such as RLS.-   3) The present invention enables a reduced amount of signalling    messages that needs to be sent in the network, which means that the    performance can be increased and the latency for resuming the    subscription is improved, especially in the case of an exploder. The    performance can also be enhanced as the functionality for    terminating and re-creating one or more client data subscriptions    according to the conventional procedures outlined in the background    section are not needed at the watching client and the client data    server, nor in any state-full proxies.

While the invention has been described with reference to specificexemplary embodiments, the description is generally only intended toillustrate the inventive concept and should not be taken as limiting thescope of the invention, which is defined by the appended claims. The IMStechnology and the SIP signalling protocol have been occasionally usedwhen describing the above embodiments, although any other standards andprotocols suitable for implementing the present invention may basicallybe used.

1. A method of withholding notifications with client data of at leastone observed client, as executed by a user equipment of a watchingclient, wherein the watching client has an ongoing subscription forreceiving said notifications from a client data server, comprising thefollowing steps: receiving by the user equipment, a subscription suspendtrigger, either as a manual user input command or automatically when theuser is occupied in a session or call or when the user has been inactivefor a preset duration; sending a subscription suspend message from theuser equipment to the client data server during the ongoing subscriptionin response to the subscription suspend trigger, the subscriptionsuspend message indicating that client data notifications should betemporarily withheld while retaining said subscription; subsequentlyreceiving by the user equipment, a subscription resume trigger, eitheras a manual user input command or automatically when the session or callis finished or when the user becomes active again after a period ofinactivity; sending a subscription resume message from the userequipment to the client data server in response to the subscriptionresume trigger, the subscription resume message indicating that thesuspended subscription shall be resumed and allowing client datanotifications to be delivered again; and subsequently receiving by theuser equipment, client data notifications according to saidsubscription.
 2. The method according to claim 1, wherein the step ofsubsequently receiving client data notifications includes receivingbuffered client data notifications retroactively in response to thesubscription resume message, after being buffered by the client dataserver during the suspension period.
 3. The method according to claim 1,wherein the client data notifications relate to plural observed clients,and said client data server is a client data aggregating serverreceiving client data notifications from plural client data serversassociated with said observed clients.
 4. The method according to claim1, wherein the subscription suspend message is an SIP SUBSCRIBE messagewith a specific indication that the subscription shall be suspended,wherein the indication is either included in a new header or added as anoptional parameter to an existing header in the SIP SUBSCRIBE message.5. The method according to claim 1, wherein the subscription resumemessage is an SIP SUBSCRIBE message with a specific indication that thesubscription shall be resumed, wherein the indication is either includedin a new header or added as an optional parameter to an existing headerin the SIP SUBSCRIBE message.
 6. The method according to claim 1,wherein said subscription suspend and resume messages are first routedto a P-CSCF node in an IMS network for further routing to the clientdata server.
 7. The method according to claim 1, wherein onlynotifications of specific observed clients or specific notificationevent types are withheld, while other notifications are allowed to bereceived during the suspension period.
 8. An arrangement in a userequipment of a watching client for withholding notifications with clientdata of at least one observed client when the watching client has anongoing subscription for receiving said notifications from a client dataserver, the arrangement comprising: means for receiving a subscriptionsuspend trigger, either as a manual user input command or automaticallywhen the user is occupied in a session or call or when the user has beeninactive for a preset duration; means for sending a subscription suspendmessage to the client data server during the ongoing subscription inresponse to the subscription suspend trigger, the subscription suspendmessage indicating that client data notifications should be temporarilywithheld while retaining said subscription; means for subsequentlyreceiving a subscription resume trigger, either as a manual user inputcommand or automatically when the session or call is finished or whenthe user becomes active again after a period of inactivity; means forsending a subscription resume message to the client data server inresponse to the subscription resume trigger, the subscription resumemessage indicating that the suspended subscription shall be resumed andallowing client data notifications to be delivered again; and means forsubsequently receiving client data notifications according to saidsubscription.
 9. A method of withholding notifications with client dataof at least one observed client to a watching client, as executed by aclient data server that provides the notifications, wherein the watchingclient has an ongoing subscription for receiving the notifications fromthe client data server, the method comprising the following steps:receiving by the client data server, a subscription suspend message fromthe watching client during the ongoing subscription, the subscriptionsuspend message indicating that the client data notifications should betemporarily withheld while retaining said subscription; withholding bythe client data server, the client data notifications while retainingsaid subscription and server resources needed for providing the clientdata notifications; subsequently receiving by the client data server, asubscription resume message from the watching client, the subscriptionresume message indicating that client data notifications should bedelivered again; and sending client data notifications from the clientdata server to the watching client according to said subscription, inresponse to said subscription resume message.
 10. The method accordingto claim 9, further comprising the steps of: buffering client datanotifications by the client data server during the suspension period;and delivering the buffered client data notifications to the watchingclient retroactively, in response to said subscription resume message.11. The method according to claim 10, wherein the step of retroactivelydelivering the buffered client data notifications includes deliveringonly notifications of specific observed clients and/or specificnotification event types, while discarding other notifications.
 12. Themethod according to claim 9, wherein the client data notificationsrelate to plural observed clients, and said client data server is aclient data aggregating server, the method further comprising receivingclient data notifications from plural client data servers associatedwith said observed clients according to individual back-endsubscriptions.
 13. The method according to claim 12, further comprisingsuspending by the client data server, all or some of the back-endsubscriptions with the client data server during the suspension period.14. The method according to claim 9, wherein the step of receiving thesubscription suspend message includes receiving a SIP SUBSCRIBE messagewith a specific indication that the subscription shall be suspended,either included in a new header or added as an optional parameter to anexisting header in the SIP SUBSCRIBE message.
 15. The method accordingto claim 9, wherein the step of subsequently receiving the subscriptionresume message includes receiving a SIP SUBSCRIBE message with aspecific indication that the subscription shall be resumed, eitherincluded in a new header or added as an optional parameter to anexisting header in the SIP SUBSCRIBE message.
 16. The method accordingto claim 9, wherein said subscription suspend and resume messages arereceived from a P-CSCF node in an IMS network, the P-CSCF node havingrouted said messages from the watching client.
 17. The method accordingto claim 9, wherein the step of withholding the client datanotifications includes withholding only some notifications of specificobserved clients and/or specific notification event types, whiledelivering other notifications during the suspension period.
 18. Anarrangement in a client data server that provides to a watching client,notifications with client data of at least one observed client, thearrangement for temporarily withholding said notifications to thewatching client when the watching client has an ongoing subscription forreceiving said notifications from the client data server, thearrangement comprising: means for receiving a subscription suspendmessage from the watching client during the ongoing subscription, thesubscription suspend message indicating that client data notificationsshould be temporarily withheld while retaining said subscription; meansfor withholding said client data notifications while retaining saidsubscription and server resources needed for providing said client datanotifications; means for subsequently receiving a subscription resumemessage from the watching client, the subscription resume messageindicating that client data notifications should be delivered again; andmeans for sending client data notifications to the watching clientaccording to said subscription, in response to said subscription resumemessage.
 19. The arrangement according to claim 18, further comprising:means for buffering client data notifications during the suspensionperiod; and means for sending the buffered client data notificationsretroactively to the watching client in response to said subscriptionresume message.
 20. The arrangement according to claim 19, wherein themeans for sending buffered client data notifications sends onlynotifications of specific observed clients and/or specific notificationevent types retroactively after the suspension period, while othernotifications are discarded.
 21. The arrangement according to claim 18,wherein the client data notifications relate to plural observed clients,and said client data server is a client data aggregating server thatreceives client data notifications from plural client data serverassociated with said observed clients according to individual back-endsubscriptions.
 22. The arrangement according to claim 21, wherein theclient data aggregating server includes means for suspending all or someof the back-end subscriptions with the client data servers during thesuspension period.
 23. The arrangement according to claim 18, whereinsaid withholding means withholds only some notifications of specificobserved clients or specific notification event types, while othernotifications are allowed to be delivered during the suspension period.